Stabilize std::num #23549

aturon · 2015-03-20T06:53:26Z

This commit stabilizes the std::num module:

The Int and Float traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
The Zero and One traits are reintroduced in std::num, which
together with various other traits allow you to recover the most
common forms of generic programming.
The FromStrRadix trait, and associated free function, is deprecated
in favor of inherent implementations.
A wide range of methods and constants for both integers and floating
point numbers are now #[stable], having been adjusted for integer
guidelines.
is_positive and is_negative are renamed to is_sign_positive and
is_sign_negative, in order to address Maybe Float::{is_positive, is_negative} should return false for 0's? #22985
The Wrapping type is moved to std::num and stabilized;
WrappingOps is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
Wrapping<X> for each concrete integer type X.

Closes #22985
Closes #21069

[breaking-change]

r? @alexcrichton

aturon · 2015-03-20T06:55:23Z

Note:

This is going to require some follow up work: there are a fair number of uses of Int and Float within the Rust distribution. In some cases, we may want to replace these with different traits, but that design work is left as a future step.
Currently, this is failing to build due to strange staging problems with the inherent wrapping_add etc methods.

huonw · 2015-03-20T07:01:32Z

src/libcore/num/wrapping.rs

+
+            #[inline(always)]
+            fn shl(self, other: $f) -> Wrapping<$t> {
+                Wrapping(self.0 << other)


I feel like these aren't actually doing the wrapping operation?

Actually I suppose they are, nvm.

Note: #22020

aturon · 2015-03-20T07:39:32Z

Update: I've resolved the staging issue. There appears to be a bad interaction between int fallback and inherent impls. In this case adding a single type annotation was enough to solve the problem.

This should probably be investigated separately in a minimal test case.

aturon · 2015-03-20T07:41:54Z

Minimal test case here: #23545 (comment)

alexcrichton · 2015-03-20T18:00:47Z

src/libcore/iter.rs

@@ -2655,6 +2656,7 @@ pub fn range_step<A: Int>(start: A, stop: A, step: A) -> RangeStep<A> {
 }

 #[stable(feature = "rust1", since = "1.0.0")]
+#[allow(deprecated)]


This seems somewhat worrisome to use these deprecated bounds in stable implementations. I think we had a problem in the past, for example, about an impl of Iterator for each concrete primitive type as a type parameter causes type inference to go awry. I forget the details, but we may want to deal with this sort of fallout sooner rather than later.

Yes, I agree; see #23549 (comment)

My only worry is that this sort of usage of Int is not warned about in the unstable lint, so we could alter this functionality of code using 100% stable code and we could still break them. This is pretty minor breakage though so it's not necessarily that bad.

alexcrichton · 2015-03-20T20:28:40Z

Could this also handle #23454? (it seems they should both be removed?)

bors · 2015-03-21T01:58:10Z

☔ The latest upstream changes (presumably #23512) made this pull request unmergeable. Please resolve the merge conflicts.

aturon · 2015-03-24T19:46:35Z

Updated, adding Zero and One, and removing many imports of Int along the way.

@alexcrichton I believe this addresses your concerns.

bors · 2015-03-24T21:05:19Z

☔ The latest upstream changes (presumably #23654) made this pull request unmergeable. Please resolve the merge conflicts.

aturon · 2015-03-24T22:57:36Z

Rebased.

alexcrichton · 2015-03-24T23:02:32Z

src/libcore/iter.rs

-            let length = (self.end - self.start).to_usize();
-            (length.unwrap_or(0), length)
-        }
-    }


This may end up having unfortunate perf side effects, but we may be able to regain it later

Indeed. There are various possibilities for regaining it (including something like ToPrimitive, or perhaps based on our new conversion traits).

That said, do you think we should worry about the hit now? This PR could be tweaked in that direction...

If we have a solution on hand I think we should implement it now, but otherwise I think we'll just have to hold off and wait.

alexcrichton · 2015-03-24T23:06:48Z

A few nits here and there, but otherwise this all looks great to me! r=me with nits updated

Manishearth · 2015-03-31T12:35:19Z

failures:

---- f32::tan_0 stdout ----
    thread 'f32::tan_0' panicked at 'test executable failed:

thread '<main>' panicked at 'assertion failed: abs_difference < f32::EPSILON', <anon>:9
', /home/ubuntu/src/rust-buildbot/slave/auto-linux-32-nopt-t/build/src/librustdoc/test.rs:246

bors · 2015-03-31T12:45:54Z

⛄ The build was interrupted to prioritize another pull request.

bors · 2015-03-31T12:45:57Z

⌛ Testing commit ea14886 with merge 4344f2a...

Manishearth · 2015-03-31T12:46:13Z

@bors: r-

This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address rust-lang#22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes rust-lang#22985 Closes rust-lang#21069 [breaking-change]

aturon · 2015-03-31T14:50:43Z

@bors: r=alexcrichton 232424d

bors · 2015-03-31T14:50:47Z

⌛ Testing commit 232424d with merge 80bf31d...

@alexcrichton

This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address #22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes #22985 Closes #21069 [breaking-change] r? @alexcrichton

@alexcrichton

This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address rust-lang#22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes rust-lang#22985 Closes rust-lang#21069 [breaking-change] r? @alexcrichton

bors · 2015-03-31T18:26:18Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

Swap order of input and output parameters of ptr::copy_nonoverlapping (rust-lang/rust#23866), remove usage of std::num::Int (rust-lang/rust#23549), change (rust-lang/rust#23860).

rust-highfive assigned alexcrichton Mar 20, 2015

huonw reviewed Mar 20, 2015
View reviewed changes

aturon force-pushed the stab-num branch from 618c769 to 763ad15 Compare March 20, 2015 07:37

aturon mentioned this pull request Mar 20, 2015

Stabilization for 1.0-beta #22500

Closed

91 tasks

alexcrichton reviewed Mar 20, 2015
View reviewed changes

aturon force-pushed the stab-num branch 2 times, most recently from 1fa1851 to ccc8ad1 Compare March 24, 2015 19:46

aturon force-pushed the stab-num branch 4 times, most recently from f5d7e07 to 911f6cd Compare March 24, 2015 20:31

aturon force-pushed the stab-num branch from 911f6cd to 73f5698 Compare March 24, 2015 22:57

alexcrichton reviewed Mar 24, 2015
View reviewed changes

aturon force-pushed the stab-num branch from ea14886 to 232424d Compare March 31, 2015 14:50

pnkfelix mentioned this pull request Mar 31, 2015

arithmetic-overflow checks during const-eval #23863

Merged

bors merged commit 232424d into rust-lang:master Mar 31, 2015

This was referenced Mar 31, 2015

repr-type specific oflo checks for enum discrim values. #23841

Closed

Make Copy a subtrait of Clone #23860

Merged

Rename tests modules to test to reflect guidelines. #23870

Closed

Lex binary and octal literals more eagerly. #23872

Merged

quantheory mentioned this pull request Apr 1, 2015

Implement associated constants #23606

Merged

alexcrichton mentioned this pull request Apr 1, 2015

Decide if Wrapping/WrappingOps should be in the prelude #23454

Closed

jshs mentioned this pull request Apr 3, 2015

Numeric traits moved to rust-lang/num PistonDevelopers/vecmath#224

Merged

aturon mentioned this pull request Apr 3, 2015

Extract math from Float trait rust-lang/rfcs#925

Closed

jooert mentioned this pull request Apr 29, 2015

Update code to compile with latest rustc. andydude/rust-bswap#6

Closed

kennytm mentioned this pull request Jul 14, 2016

Unified machine word trait rust-lang/rfcs#1676

Closed

Mark-Simulacrum mentioned this pull request May 6, 2017

Wrapping<_> implements ShX<usize> but wrapping_shX takes u32 #34809

Open

cuviper mentioned this pull request Dec 21, 2017

Add rsqrt method to Float trait rust-num/num-traits#1

Open

SimonSapin mentioned this pull request Jun 21, 2018

Tracking issue for the to_bytes and from_bytes methods of integers #49792

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize std::num #23549

Stabilize std::num #23549

aturon commented Mar 20, 2015

aturon commented Mar 20, 2015

huonw Mar 20, 2015

huonw Mar 20, 2015

aturon Mar 20, 2015

aturon commented Mar 20, 2015

aturon commented Mar 20, 2015

alexcrichton Mar 20, 2015

aturon Mar 20, 2015

alexcrichton Mar 20, 2015

alexcrichton commented Mar 20, 2015

bors commented Mar 21, 2015

aturon commented Mar 24, 2015

bors commented Mar 24, 2015

aturon commented Mar 24, 2015

alexcrichton Mar 24, 2015

aturon Mar 24, 2015

alexcrichton Mar 24, 2015

alexcrichton commented Mar 24, 2015

Manishearth commented Mar 31, 2015

bors commented Mar 31, 2015

bors commented Mar 31, 2015

Manishearth commented Mar 31, 2015

aturon commented Mar 31, 2015

bors commented Mar 31, 2015

bors commented Mar 31, 2015

Stabilize std::num #23549

Stabilize std::num #23549

Conversation

aturon commented Mar 20, 2015

aturon commented Mar 20, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aturon commented Mar 20, 2015

aturon commented Mar 20, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Mar 20, 2015

bors commented Mar 21, 2015

aturon commented Mar 24, 2015

bors commented Mar 24, 2015

aturon commented Mar 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Mar 24, 2015

Manishearth commented Mar 31, 2015

bors commented Mar 31, 2015

bors commented Mar 31, 2015

Manishearth commented Mar 31, 2015

aturon commented Mar 31, 2015

bors commented Mar 31, 2015

bors commented Mar 31, 2015